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METHOD AND SYSTEM FOR 
AN ONLINE-LIKE ACCOUNT PROCESSING AND MANAGEMENT 



Field of Invention 

The present invention relates to records processing techniques and more 
particularly a processing technique for enabling processing of batch records in an online-like 



manner 



Background of Invention 

The present invention will be described as it relates to insurance accounts 
management systems and techniques, however, it should be understood to be equally 
applicable to other industries and records processing systems as well. 

Batch processing account management systems have existed for some time. 
An account can be defined as one or more insurance policies of an insured which are billed 
and managed together. These batch processing techniques are used to update accounts, e.g. 
establish receivables, credit payments made to existing or new accounts, change account 
information and generate appropriate communications for example. These batch processes 
are typically run at predetermined intervals, e.g. once each cycle. A cycle can be defined as 
a 24 hour period or any other period defined by business practices for example. 

As is well known, during batch processing, access to any account that will be 
processed with the batch typically must be disadvantageously denied. In other words, 
accounts to be processed with the batch need to be locked for the duration of processing that 



i^raessine svstems conventionally reaui^^e 



batch. Thus, batch processing systems conventionally requi^hese accounts to be locked 
for a significant amount of time to permit completion of the entire batch, even though 
processing for any individual account in the batch typically only takes a small percentage of 
the batch duration. This is because multiple simultaneous access to an account must be 
avoided to ensure account reliability and confidence, and because there is no conventional 
way of knowing which account in a batch is currently being processed or will be processed 
next. Accordingly, access to all accounts that will be effected by the batch process is 
conventionally denied, e.g. these accounts are locked, for the entire duration of the batch 
process. Accordingly, these batch processes are typically run in off-hour, when access to 
account information has traditionally not been required. 

For any number of reasons however, as is the case with many industries today, 
off-hour periods are rapidly being reduced in magnitude and frequency. Hence, opportunities 
to execute such batch processes, and windows of opportunity for completing them, are 
rapidly diminishing. 

Additionally, it is desirable to have a management and processing system 
capable of operating in real-time. In other words, it is desirable to have an account 
management system that fully processes an account as actions are performed in relation to 
it. As is understood by those possessing ordinary skill in the pertinent art, conventional batch 
processes are typically incompatible with such a system, as account processing is delayed 
until an entire batch is run. 

A further drawback of conventional batch processing lies in the realization 
that if any errors or problems are encountered during the batch process, typically the entire 



batch process must be repeated. In other words the batch in its entirety typically passes or 
fails. 

Summary of Invention , 
method and system for emulating online-like transaction processing of 
account information contained in batch process files, the method including: reading at least 
one batch file containing a plurality of records, each of the plurality of records being related 
to an associated oneW a plurality of accounts; identifying which of the plurality of records 
relate to same ones W the plurality of accounts; identifying one of the accounts, and, 
processing all of the records identified as relating to the one of the accounts prior to 
processing any of the records relating to any other of the plurality of accounts. 

Brief Description of the Figures 

The advantages and aspects of the present invention will be more fully 
understood in conjunction with the following detailed description and accompanying 
drawings, wherein: 

Figure 1 illustrates an overview of account level processing according to a 
preferred form of the present invention; 

Figure 2 illustrates an overview of a on-online transaction processing 
emulation cycle utilized according to a preferred embodiment of the present invention; 

Figure 3 illustrates an interaction between cycle control and bill account 
processing control according to the present invention; 




Figure 4 illustrates a more detailed view of on-line account level transaction 
processing emulation according to the present invention; 

Figure 5 illustrates interaction between a control account level processing 
component and account level processing according to the present invention; and, 

Figure 6 illustrates an interaction between cycle control, bill account process 
control and an account level processing stage processing. 

Detailed Description of the Invention 

The present invention is a method for processing otherwise batch files using 
a pseudo-online transaction processing (OLTP) technique (online-like technique) and then 
providing outputs as batch files. The present system is particularly useful for Receivables 
Management Services (RMS) in a billing application of insurance policy holders. The 
present invention essentially enables access to accounts by persons and other systems nearly 
24 hours a day, 7 days a week, 52 weeks a year. The present invention further allows for the 
processing window or time frame to become scalable as a function of volume. Essentially, 
the present invention changes the nature of batch processing, moving overnight processes to 
an online-like model capable of running anytime. It also allows for a method for splitting 
the continuous operational aspects of the processing from reporting and backup processes. 

Figure 1 illustrates an overview of account level processing according to a 
preferred form of the present invention. One or more files are fed 1000 from a flat file or 
batch source that contains a daily journal of cash, premiums and accounts to be billed for 



example. This can be accomplished utilizing tape records for example. The present 
invention reads the input files, and validates the records 1 integrity 1010. 

The validated records are staged 1020 in a staging table 1030 according to 
cash, billing and other queued up jobs as staged records (AC1, AC2...). These staged records 
preferably include a level of detail sufficient to enable processing of the accounts to which 
they relate, e.g. are effected by the transaction reflected in the record. 

After all records are staged 1040, the system sweeps 1050 the staging table 
1030 and creates work queue 1060 which includes index-like entries which identify each of 
the records staged to table 1030. The next step 1070 generates distinct accounts table 1080 
by scanning the work queue 1060 and identifying each unique, or distinct account found 
therein regardless of the number of entries found in the work queue 1060 corresponding to 
it. According to the present invention, records from staging table 1030 are selected for 
processing by dequeuing 1090 entries from work queue table 1060 according to entries in the 
distinct accounts table 1080. More particularly, the next account to be processed is dequeued 
from the distinct accounts table 1080, the work queue 1060 is scanned for entries for that 
selected account, and the corresponding entry in the staging table 1030 is processed 1 100 for 
each entry found for the selected account in work queue 1060. Processing 1100 includes 
debiting accounts for payments received, reconciling total cash input and creating bills for 
example. Results may be updating a customer's payment record or sending out a customer 
bill for example. Records indicative of these results are then staged 1 1 10 to at least one 
output staging table, and the output staging table is fed out for further processing 1120 at 
preselected intervals or upon predetermined events consistent with design criteria. 



In other words, by changing the unit of work from a batch file to an individual 
account, the present invention simulates online transaction processing for each individual 
account. This represents a significant departure from conventional batch processing 
methodology. One or more flat files which each includes sequential records with traditional 
headers, trailers and balancing data, and reflecting account activities for example, are 
supplied to the present system consistently with those provided a conventional batch 
processing system. Therefore, legacy front end user interfaces and data entry systems and 
techniques advantageously need not be changed to implement the present invention. 

The primary data feeds used as input at step 1000 include cash and premiums 
information, as well as a few additional data feeds in the preferred embodiment. These data 
feeds can be supplied as flat files or database tables for example. By staging the input data 
1020 to one or more staging tables 1030, individual records may be screened, updated, 
sorted, edited or deleted for example. As is understood by those possessing ordinary skill 
in the art, multiple records can often relate to a single account. A particular example being 
where payments are due for multiple policies of a single insured, e.g. home and automobile. 

During dequeuing 1090, the account to be processed at step 1100 is locked 
out, and each record in the one or more staging tables 1030 that relates or effects it is 
processed such that all records that relate to that single account are processed together before 
any records that relate to other accounts are processed. In this way, all transactions that 
effect a given account are processed together, and the remaining accounts which will not be 
effected by the processing need not be locked. When processing 1100 of all records in 
staging table 1030 which relate to the single account being processed are completed, that 



account can be unlocked and another account locked for processing. In this way, the present 
invention enables all accounts except the one being immediately processed to remain 
unlocked and hence accessible to access or other processes. In contrast to batch systems, 
where all of the accounts to be processed must be locked for a significant amount of time to 
permit completion of the batch, the processing of any one particular account often only takes 
a small amount of time (often only seconds). Accordingly, each account to be processed is 
only locked for a negligible amount of time during a given cycle and is hence available 
nearly 24 hours per day, 7 days a week, 52 weeks per year. 

Once all records in staging table 1030 that relate to the account being 
processed have been processed 1100, output flat files arc preferably created 1120 as batch 
processing data feeds to other legacy processes and system. In this way, legacy batch 
processing systems which utilize the output of the present invention system and method 
advantageously need not be immediately updated or replaced. 

It should be understood, that as the present system and method processes 
accounts individually, and while the preferred embodiment disclosed herein is 
advantageously backwards compatible in that it is operable with legacy batch processing 
front and back ends, it is recognized the present invention is suitable for use with real-time 
front and back ends as well. 

Referring now also to Figure 2, therein is illustrated an overview of an online 
transaction processing (OLTP) -like cycle 10 utilized according to a preferred embodiment 
of the present invention. The cycle 10 includes data feeds 30, processing stage 20 and post 
processing output staging tables 40. As individual accounts are processed at processing stage 



20 using data supplied by feeds 30, other processes will need to be called as is well 
understood. The present invention addresses this reality by entering records in output tables 

40 to be supplied to these appropriate further processes. Of course, other methods of 
providing data to other systems or subjecting that data to other processes could alternatively 
be utilized. In other words, processing at stage 20 for a particular account may indicate that 
collection procedures should be invoked. In such a case, an entry is made in CAMS table 

41 which is fed to the CAMS system. A description of the CAMS system can be found in 
commonly assigned United States Patent 5,991,733 entitled "METHOD AND 
COMPUTERIZED SYSTEM FOR MANAGING INSURANCE RECEIVABLE 
ACCOUNTS", issued November 23, 1999, the entire disclosure of which is hereby 
incorporated by reference as if being set forth in its entirety herein. The output tables 40 are 
swept and the data contained therein fed 1 120 to other- post processing stages at extract feed 
data stage 50 and a trial balance for the account is determined for accounting purposes at trial 
balance generation stage 60. According to the preferred embodiment as is illustrated in 
Figure 2, data feeds 30 which are input 1000 include: premiums or NPPS data feed 32; non- 
financial data or by-pass data feed 33; and, cash or payment feeds 34 and 35. Preferably, one 
of the payment feeds 34, 35 includes in-house financial transactions while the other includes 
financial data from financial institutions such as banks and credit unions. 

Incoming data from feeds 30 is preferably processed in two waves. The first 
wave processes all data for each preexisting account, this is referred to as account level 
processing 24. The second wave processes data from NPPS feed 32 and by-pass feed 33 that 
was not processed during account level processing 24 because an account identifier, such as 



account number, was not preexisting, e.g. they relate to new accounts. This second wave of 
processing is called new account processing 26. As will be understood by those possessing 
ordinary skill in the pertinent art, the majority of data processed by processing stage 20 will 
be handled by account level processing 24. The new account processing 26 enables new 
accounts to be entered into the system, so they may be treated in future iterations using 
account level processing 24. As was discussed relating to Figure 1, the data form feeds 30 
is loaded 1000 and staged 1020, onto one or more staging tables 1030 at staging stage 22. 

Referring now also to Figure 3, therein is illustrated the inter-relation of cycle 
control 100 and bill account process control 110. The cycle control structure 100 controls 
what business cycles are being run, e.g. a daily cycle for Monday for example. The cycle 
control 100 preferably uses: a business cycle ID to indicate what cycle is being run, the 
account date which is utilized to determine, whether a record has been processed during a 
past cycle and define starting and ending constraints for the cycle, feed statuses to determine 
which of feeds 30 are currently available, and other processing constraints such as financial 
balancing and financial controls for example. Bill account process control 110 manages 
accounts identified as ones which still need to be processed during the cycle identified by 
cycle control 100. For each individual account being processed, the control 1 10 tracks: the 
bill account number for the account currently being processed, a process identifier for 
identifying what process the current account is undergoing; and, a process status for 
determining the status of the present process. In other words, bill account process controls 
110 controls dequeuing 1090 from work queue 1060. The bill account process control 
further serves to lock the account currently being processed 1 100 to prevent multiple access 



to that single account. It should be noticed there are typically many accounts which are 
processed responsively to bill account processing control 1 10 for each cycle identified by 
cycle control 100. 

It should also be understood that once configured, cycle control 100 is mainly 
autonomous in that it follows a scheduled course of events. However, changes often need 
to be made to processing cycles for one or more reasons as are recognized by those 
possessing ordinary skill in the art. An example being such as when a national holiday falls 
on what would otherwise be a scheduled cycle day. In such a case, a cycle scheduled for that 
day may need to be postponed for business reasons. In a preferred form, an administrator can 
interact with the cycle control 100 to reschedule or cancel cycles for example. 

Referring now also to figure 4, therein is illustrated a more detailed view of 
a preferred form of online-like account level transaction processing 24 according to the 
present invention. As set forth the data feeds 30 are individually supplied to account level 
processing stage 24. Records from each of the feeds 30 are selected for processing as has 
been set forth regarding Figure 1, e.g. the data feeds are staged 1020, swept to create work 
queues 1060, distinct accounts are queued up 1070 and records from staging table 1030 
corresponding to dequeued entries 1090 from work queue 1060 are selected for processing 
24. For each individual account selected to be processed 1100 using account level 
processing 24 according to the present invention, if available, non-financial, or bypass data 
33 is first loaded and scrubbed, or edited to verify critical components thereof, e.g. select 
fields contain valid data, at step 160. It should be understood this alternatively can be 
performed during validation 1010 as set forth regarding Figure, 1. The bypass data 33 
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includes contact information, e.g. name and address, for example. Premiums data 32 is then 
loaded and matched 170 with scrubbed data 33. Premiums data preferably includes an 
account number and insurance policies information for example. By matching 170 scrubbed 
data 33 with premiums (NPPS) data 32, contact information as well as policies information 
is matched up, and both are available for the processing 24. The establish receivables and 
establish payables steps 180 and 190 are terms used in the art for determining what payments 
are due and what amount is actually owing as of the time of processing 24. A common 
example of implementing these steps is seen when an insurance company determines how 
much money is owed by an insured for a policy term, and what the current amount due of 
that amount owed is, e.g. a one year automobile insurance policy having 12 monthly or 4 
quarterly payments due. After completion of the steps 180 and 190, it is established what 
amounts are due for the account currently being processed at present. 

Feeds 34 and 35 are utilized by account level processing 24 at apply payments 
step 200 and system reconciliation step 210. At step 200 payments received are applied 200 
against account receivables and payables which have been established at steps 180 and 190. 
At reconciliation step 210, the account is reconciled, e.g. deficiencies or overpayments for 
the account being processed are determined, so data may be fed to appropriate ones of the 
tables 40. Before entries are made in tables 40, or another account is locked for processing 
though, the system loads feeds 30 that were determined to include additional transactions 
relating to the current account by scanning work queue 1060 during dequeuing 1090. When 
no further records within staging table 1030 correspond to the account currently being 
processed, entries are prepared for output staging tables 40. 
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Further processing 220 is performed to generate appropriate entries for tables 
40. An entry is made using function 221 , system disbursements, when reconciliation at step 
210 determines overpayments have been made and an amount should be refunded. An entry 
is made using function 222 when a first notice that a payment is due should be produced 
according to business practices. This can be in response to the current business cycle as 
determined by cycle control 100 corresponding to the billing day for an account. Such 
records can be introduced through data feed table 36, bill account. The account selection 
process makes appropriate entries in the staging table 1030 for these accounts. An entry is 
made using function 223 when a second notice that a payment is due should be produced as 
determined by processing 24 and reconciliation 210 particularly. Likewise, an entry is made 
using function 224 when a direct notice of cancellation (DNOC) should be prepared. 
Similarly, an entry is made using function 225 when cancellation of a policy if a payment 
was not received should be invoked. As is understood by those possessing ordinary skill in 
the pertinent art, this typically causes another premiums record to be entered in the NPPS, 
or premiums feed 32. When a cancellation is effected, an entry is made using earned 
premiums function 226. And, if earned premiums are not billed and collected, transfers to 
collections can be effected by suitable entries being made using function 227. It should be 
understood that the further processing steps to actually perform these tasks are well 
understood and currently implemented by many business entities and that all appropriate 
processing for each individual account for the present business cycle is performed before the 
account is effectively released and the output tables 40 converted 50 for transfer to other 
systems. It should be understood these functions are merely exemplary and not all 
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encompassing, as many other functions can be utilized which implement suitable business 
logic according to the present invention. For example, function 222, produce first notice, 
causes an appropriate entry to be made in invoice output staging table 42 as is illustrated in 
Figure 2. 

Referring now also to Figure 5, therein is illustrated the preferred relationship 
between the bill account processing control 1 10 and account level processing 24. Processing 
24 is launched and executed responsively to bill account processing control 110. The bill 
account process control structure 1 10 causes the appropriate processes for a given account 
to be executed from start to finish. When the given process is executed the status is 
appropriately updated. 

It should be understood, that during the establish receivables process 180, a 
cancellation can cause the bill account off cycle date to be set to the current date. This causes 
an entry to be made in the bill account process control structure 1 10 for that account insuring 
that system reconciliation and billing will be done. 

Referring now also to Figure 6, therein is illustrated a more detailed view of 
the interaction between cycle control 100, bill account processing control 110 and processing 
24. As set forth, the cycle control 100 identifies and controls what cycles are being executed. 
Bill account process control 1 10 determines and controls which accounts will be processed 
24 and locks and unlocks the account actually being processed. 

It should be understood in the referred form many processes 24 can be run in 
parallel to speed processing 1 100 of the work queue 1060 using conventional methodology. 
In such a case only those accounts currently being processed by one of the parallel systems 
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are locked, as each system essentially runs autonomously using a common staging table 
1030, work queue 1060, distinct accounts table 1080 and output staging tables 40. 

The hardware utilized in the new system preferably includes a database server 
(four Compaq GS140s), an I/O subsystem utilizing an EMC Symmetrix Array having 3.7 
Terabytes, 3-way mirror; cluster technology utilizing a Compaq Tru-Cluster and a Tape 
back-up System utilizing a Compaq ESL9326. The systems software preferably operates an 
Oracle 8i database. Of course, it should be understood these are merely a matter of design 
choice and is not intended to limit the scope of the invention to the equipment denoted. 

Although the invention has been described and pictured in a preferred form 
with a certain degree of particularity, it is understood that the present disclosure of the 
preferred form, has been made only by way of example, and that numerous changes in the 
details of construction and combination and arrangement of parts may be made without 
departing from the spirit and scope of the invention as hereinafter claimed. It is intended that 
the patent shall cover by suitable expression in the appended claim, whatever features of 
patentable novelty exist in the invention disclosed. 
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